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Amendments to the Specification: 

Please amend page 14 by deleting the title and inventor name. 
Also, please amend the body of the abstract as follows. A clean copy of the 
following abstract is included on a separate sheet, after the Remarks section. 

A packet crosspoint that cross - conn e cts asynchronous UBR (unsp e c i fi e d bit rato) 
pack e t traff i c r e c ei v e d at n i nputs to any of n outputs i s d i sc l os e d that buff e rs th e pack e ts 
at both the n input ports as w ell as th e n output ports. Th e crosspo i nt works with an arbiter 
to control the number of packets being received at the input ports of the cross-connect 
from traffic sources coupled thereto. This is accomplished by monitoring the number of 
packets waiting in buffers in the output ports, as well as the number of other packets which 
the arbiter has already granted for transmission to the input ports of the cross-connect, but 
which have not as of yet been received in the output queue of the destination output port. 
Th i s mochanism servos to koop tho input port buffer from back i ng up to avo i d "head of 
l in e " b l ock i ng problems. The number of grants i ssued by an arb i ter can a l so bo thrott l ed 
bas e d on back pressure s i gnals prov i ded by tho i nput buffers i n tho ovon that thoy start to 
back up to avoid los i ng packets whon input buffers overf l ow. An audit mechanism is 
included for ensuring that output port grant counters do not drift upward based on the fact 
that some granted packets are lost in the system. F i na ll y, back - pr e ssur e may also bo 
a ss e rt e d by th e d e st i nat i on for traff i c output from th e cross conn e ct to s l ow down tho 
output of cross connectod traffic i n tho ovont that thoy oro i ssued factor than tho traff i c 
r e c ei v e r can proc e ss th e m. 



Please amend a paragraph at page 2 lines 6-18 as follows. 

Until recently, service providers have had to maintain separate network fabrics (or 
overlays) to handle these various classes of traffic. Maintaining separate overlays is 
expensive and makes network management very complex. As a result, application of 
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mixed class access systems to the lower end of the network is too costly. Thus, it would be 
highly desirable to provide a single network access system that is capable of flexibly 
handling a broad mix of traffic classes, including both synchronous and asynchronous 
traffic types. Further, it would be desirable for this system to be capable of flexible 
configuration to perform multiple network functions such as network access system, a 
digital loop carrier (DLC), a transport level add/drop mux, etc. Such a system would require 
as one of its components an asynchronous packet cross-connect to route the 
asynchronous traffic such as UBR (unspecified bit rate) in the form of ATM unicast traffic. 
Those of skill in the art will recognize that an access system capable of handling a broad 
mix of traffic classes will require novel and non-obvious methods and apparatuses. 



Please amend a paragraph at page 2 line 20 to page 3 line 7 as follows. 



The An asynchronous cross-connect of tho prosont in accordance with the 
invention switches asynchronous packet data, received from one or more traffic sources, 
between a p l ura li ty of I /O input and output ports. Both the input and output ports are 
buffered. The outputs are buffered in the event that once cross- connected, the packets 
may have to wait before they can be read from the output port by their respective data 
sinks. The number of packets permitted to be released to roco i vo and ctoro packoto are 
stored until they can be transmitted between their input and destination ports, and further 
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until the data is released from the output port to its destination in a network. The number of 
packets being sent to the inputs of the cross-connect is controlled by the number of grants 
issued by an arb i trat i on un i t arbiter to the traffic sources. The rate of grants is controlled by 
several signals. First, there is a threshold on the number of packets allowed in the output 
buffers. If the number is exceeded, a signal is issued to cease grants for the output having 
the full buffer. Additionally, tho arbiter a grant counter associated with each output keeps 
track of all packets in the system for eaeb that output, and if the total number of packets in 
the system exceeds some threshold, the arbiter ceases granting any packets until the 
number of packets in the system destined for a particular output falls below some number. 
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The output buffers are regulated first to avoid affecting the inputs and risking head-of-line 
blocking. Add i t i ona ll y, tho input bufforo a l co provido a baokprooouro c i gna l whon tho i r 
thresho l d is oxcoodod. Finally a grant audit is conducted periodically to prevent upward 
drift in grant counters on the outputs due to the loss of packets not received by the output 
buffers. 
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Please amend a paragraph at page 4 line 26 to page 5 line 10 as follows. 

The arbiter 12 determines when packets are granted based on the VOQ images 
(queue occupancy) it maintains and the bandwidth allocation that has been provisioned for 
each of the source line cards 16a. Depending upon the type of line unit, an access 
processor (GAP) 22 or a routing and switch processor (RSP) 24 appends flow 
identification, routing information, and other overhead control fields to the incoming 
packets 26. A packet is transferred to the packet cross-connect 10 in a 64 byte format. 
The 64 byte fixed length packet (FLP) may be either an extended ATM cell or a data 
packet. The packet is connected via the packet cross-connect 10 to a destination output 
19a-n based on the routing map included in the header of the packet. At the output, 
depending on the type of line unit 16b, the GAP 22 or the RSP 24 strips the appended flow 
identification and routing map information and transmits out from the system through 
physical interface circuit (PHY) 28. For detailed information regarding an embodiment of a 
system such as the one just disclosed, refer to related and co-filed U.S. Application 
Attornoy Docket No. M 1 1600 US 09/874.352 entitled "Concurrent Switching of 
Synchronous and Asynchronous Traffic" by Jason Dove et al., and which is incorporated 
herein in its entirety, including all Figures and Attachments, by this reference 



Please amend a paragraph at page 8 lines 7-12 as follows. 

T-hee J_he output port controller I22a-n performs the following functions. It arbitrates 
among multiple input ports 88a-n requesting a transfer of a packet to the associated output 
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FIFO 101a-n. Each output port controller's arbiter (150a-n, Fig. 5) examines the routing 
map assembled from the input FIFOs 100a-n and performs a round-robin arbitration. After 
determining a winner, the arbiter (150a-n, Fig. 5) performs the control operations that 
transfer the packet from input to output. 



Please amend a paragraph at page 1 1 line 26 to page 12 line 5 as follows. 

[[5.]] When the "Terminate Grant Audit" type VOQ arrival message is received by 
the packet cross-connect 10, it translates the strobeA/OQ data to the appropriate 
strobe/grant counter identifier and enters the information in a queue that operates in 
parallel with the associated input FIFO. The audit terminate flag emerges from the queue 
and is passed to the output port as the packet it arrived with is transferred across the 
cross-connect. When the output port controller receives the terminate flag, the decrement 
of the saved grant counter is stopped after counting the associated packet. Any remainder 
in the counter indicates the amount of error. The remainder is automatically applied to the 
grant counter under audit to correct the error. The termination and amount of error are 
reported to management software. This prevents any of the grant counters from drifting 
upwards due to lost packets granted but not processed. 
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Please amend a paragraph at page 12 lines 6-16 as follows. 

Those of skill in the art will recognize that the packet cross-connect of the present 
invention is not tied to the system in which such a cross-connect can reside. The system 
context provided herein is exemplary only, and is used to convey the manner in which the 
cross-connect of the present invention would interact with such a system. Provided that 
similar interface signals are provided between the cross-connect of the present invention 
and the system context in which it is employed, the present invention, as well as the 
features thereof, remains patentably distinct from the system. For more information 
regarding the interface and implementation details of the present invention, please refer to 
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the GRX ASIC Packet Crosspoint Module Specification, attached as Attachment C to 
related and co-filed U.S. Application Attorney Docket No. M 1160Q US 09/874.352 
entitled "Concurrent Switching of Synchronous and Asynchronous Traffic" by Jason Dove 
et al. 
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